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Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document clarifies the use of addresses in Generalized 
Multiprotocol Label Switching (GMPLS) networks. The aim is to 
facilitate interworking of GMPLS-capable Label Switching Routers 
(LSRs). The document is based on experience gained in 
implementation, interoperability testing, and deployment. 


The document describes how to interpret address and identifier fields 
within GMPLS protocols, and how to choose which addresses to set in 
those fields for specific control plane usage models. It also 
discusses how to handle IPv6 sources and destinations in the MPLS and 
GMPLS Traffic Engineering (TE) Management Information Base (MIB) 
modules. 


This document does not define new procedures or processes. Whenever 


this document makes requirements statements or recommendations, these 
are taken from normative text in the referenced RFCs. 
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1. Introduction 


This informational document clarifies the use of addresses in 
Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] networks. 
The aim is to facilitate interworking of GMPLS-capable Label 
Switching Routers (LSRs). The document is based on experience gained 
in implementation, interoperability testing, and deployment. 


The document describes how to interpret address and identifier fields 
within GMPLS protocols (RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], and 
GMPLS ISIS [RFC4205]), and how to choose which addresses to set in 
those fields for specific control plane usage models. 


This document does not define new procedures or processes and the 
protocol specifications listed above should be treated as definitive. 
Furthermore, where this document makes requirements statements or 
recommendations, these are taken from normative text in the 
referenced RFCs. Nothing in this document should be considered 
normative. 


This document also discusses how to handle IPv6 sources and 
destinations in the MPLS and GMPLS Traffic Engineering (TE) 
Management Information Base (MIB) modules [RFC3812], [RFC4802]. 


2. Terminology 


As described in [RFC3945], the components of a GMPLS network may be 


separated into a data plane and a control plane. The control plane 
may be further split into signaling components and routing 
components. 

A data plane switch or router is called a data plane entity. It is a 


node on the data plane topology graph. A data plane resource is a 
facility available in the data plane, such as a data plane entity 
(node), data link (edge), or data label (such as a lambda). 


In the control plane, there are protocol speakers that are software 
implementations that communicate using signaling or routing 
protocols. These are control plane entities, and may be physically 
located separately from the data plane entities that they control. 
Further, there may be separate routing entities and signaling 
entities. 
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GMPLS supports a control plane entity that is responsible for one or 
more data plane entities, and supports the separation of signaling 
and routing control plane entities. For the purposes of this 
document, it is assumed that there is a one-to-one correspondence 
between control plane and data plane entities. That is, each data 
plane switch has a unique control plane entity responsible for 
participating in the GMPLS signaling and routing protocols, and that 
each such control plane presence is responsible for a single data 
plane switch. 


The combination of control plane and data plane entities is referred 
to as a Label Switching Router (LSR). 


Note that the term 'Router ID’ is used in two contexts within GMPLS. 
It may refer to an identifier of a participant in a routing protocol, 
or it may be an identifier for an LSR that participates in TE 
routing. These could be considered as the control plane and data 
plane contexts. 


In this document, the contexts are distinguished by the following 
definitions. 


o Loopback address: A loopback address is a stable IP address of the 
advertising router that is always reachable if there is any IP 
connectivity to it [RFC3477], [RFC3630]. Thus, for example, an 
IPv4 127/24 address is excluded from this definition. 


o TE Router ID: A stable IP address of an LSR that is always 
reachable in the control plane if there is any IP connectivity to 
the LSR, e.g., a loopback address. The most important requirement 
is that the address does not become unusable if an interface on 
the LSR is down [RFC3477], [RFC3630]. 


o Router ID: The OSPF protocol version 2 [RFC2328] defines the 
Router ID to be a 32-bit network-unique number assigned to each 
router running OSPF.  IS-IS [RFC1195] includes a similar concept 
in the System ID. This document describes both concepts as the 
"Router ID" of the router running the routing protocol. The 
Router ID is not required to be a reachable IP address, although 
an operator may set it to a reachable IP address on the same node. 


o TE link: "A TE link is a representation in the IS-IS/OSPF Link 
State advertisements and in the link state database of certain 
physical resources, and their properties, between two GMPLS nodes" 
[RFC3945]. 


o Data plane node: A vertex on the TE graph. It is a data plane 
switch or router. Data plane nodes are connected by TE links that 
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are constructed from physical data links. A data plane node is 
controlled through some combination of management and control 
plane actions. A data plane node may be under full or partial 
control of a control plane node. 


o Control plane node: A GMPLS protocol speaker. It may be part of a 
data plane switch or may be a separate computer. Control plane 
nodes are connected by control channels that are logical 
connection-less or connection-oriented paths in the control plane. 
A control plane node is responsible for controlling zero, one, or 
more data plane nodes. 


o Interface ID: The Interface ID is defined in [RFC3477] and in 
Section 9.1 of [RFC3471]. 


o Data Plane Address: This document refers to a data plane address 
in the context of GMPLS. It does not refer to addresses such as 


E.164 SAPI in Synchronous Digital Hierarchy (SDH). 


o Control Plane Address: An address used to identify a control plane 
resource including, and restricted to, control plane nodes and 
control channels. 


o IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit 
field, whichever is applicable. 


o TED: Traffic Engineering Database. 
o LSR: Label Switching Router. 
o FA: Forwarding Adjacency. 
o IGP: Interior Gateway Protocol. 

3. Support of Numbered and Unnumbered Links 
The links in the control and data planes may be numbered or 
unnumbered [RFC3945]. That is, their end points may be assigned IP 
addresses, or may be assigned link IDs specific to the control plane 
or data plane entity at the end of the link.  Implementations may 
decide to support numbered and/or unnumbered addressing. 
The argument for numbered addressing is that it simplifies 
troubleshooting. The argument for unnumbered addressing is to save 


on IP address resources. 


An LSR may choose to only support its own links being configured as 
numbered, or may only support its own links being configured as 
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unnumbered. But an LSR must not restrict the choice of other LSRs to 
use numbered or unnumbered links since this might lead to 
interoperablity issues. Thus, a node should be able to accept and 
process link advertisements containing both numbered and unnumbered 
addresses. 


Numbered and unnumbered addressing is described in Sections 4 and 5 
of this document, respectively. 


4. Numbered Addressing 


When numbered addressing is used, addresses are assigned to each node 
and link in both the control and data planes of the GMPLS network. 


A numbered link is identified by a network-unique identifier (e.g., 
an IP address). 


4.1. Numbered Addresses in IGPs 


In this section, we discuss numbered addressing using two Interior 
Gateway Protocols (IGPs) that have extensions defined for GMPLS: 
OSPF-TE and IS-IS-TE. The routing enhancements for GMPLS are defined 
in [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205]. 


4.1.1. Router Address and TE Router ID 


The IGPs define a field called the "Router Address". It is used to 
advertise the TE Router ID. 


The Router Address is advertised in OSPF-TE using the Router Address 
TLV structure of the TE Link State Advertisement (LSA) [RFC3630]. 


In IS-IS-TE, this is referred to as the Traffic Engineering router 
ID, and is carried in the advertised Traffic Engineering router ID 
TLV [RFC3784]. 


4.1.2. Link ID and Remote Router ID 
In OSPF-TE [RFC3630], the Router ID of the remote end of a TE link is 
carried in the Link ID sub-TLV. This applies for point-to-point TE 
links only; multi-access links are for further study. 
In IS-IS-TE [RFC3784], the Extended IS Reachability TLV is used to 


carry the System ID. This corresponds to the Router ID as described 
in Section 2. 
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4.1.3. Local Interface IP Address 
The Local Interface IP Address is advertised in: 
o the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630] 
o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784]. 
This is the ID of the local end of the numbered TE link. It must be 
a network-unique number (since this section is devoted to numbered 
addressing), but it does not need to be a routable address in the 
control plane. 


4.1.4. Remote Interface IP Address 


The Remote Interface IP Address is advertised in: 


o the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630] 

o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784]. 

This is the ID of the remote end of the numbered TE link. It must be 
a network-unique number (since this section is devoted to numbered 
addressing), but it does not need to be a routable address in the 
control plane 


4.2.  Numbered Addresses in RSVP-TE 


The following subsections describe the use of addresses in the GMPLS 
signaling protocol [RFC3209], [RFC3473]. 


4.2.1. IP Tunnel End Point Address in Session Object 


The IP tunnel end point address of the Session Object [RFC3209] is 
either an IPv4 or IPv6 address. 


The Session Object is invariant for all messages relating to the same 
Label Switched Path (LSP). The initiator of a Path message sets the 
IP tunnel end point address in the Session Object to one of: 


o The TE Router ID of the egress since the TE Router ID is routable 
and uniquely identifies the egress node. 


o The destination data plane address to precisely identify the 
interface that should be used for the final hop of the LSP. That 
is, the Remote Interface IP Address of the final TE link, if the 
ingress knows that address. 
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4 


4 


<2 


The IP tunnel end point address in the Session Object is not required 
to be routable in the control plane, but should be present in the 
TED. 


2s 


IP Tunnel Sender Address in Sender Template Object 


The IP tunnel sender address of the Sender Template Object [RFC3209] 
is either an IPv4 or IPv6 address. 


When an LSP is being set up to support an IPv4-numbered FA, [RFC4206] 
recommends that the IP tunnel sender address be set to the head-end 
address of the TE link that is to be created so that the tail-end 
address can be inferred as the /31 partner address. 


When an LSP is being set up that will not be used to form an FA, the 
IP tunnel sender address in the Sender Template Object may be set to 
one of: 


o 


22s 


3 


The TE Router ID of the ingress LSR since the TE Router ID is a 
unique, routable ID per node. 


The sender data plane address (i.e., the Local Interface IP 
Address). 


IF ID RSVP HOP Object for Numbered Interfaces 


There are two addresses used in the IF ID RSVP HOP object. 


Ts 


The IPv4/IPv6 Next/Previous Hop Address [RFC3473] 


When used in a Path or Resv messages, this address specifies the 
IP reachable address of the control plane interface used to send 
the messages, or the TE Router ID of the node that sends the 
message. That is, it is a routable control plane address of the 
sender of the message and can be used to send return messages. 
Note that because of data plane / control plane separation (see 
Section 7.1) and data plane robustness in the face of control 
plane faults, it may be advisable to use the TE Router ID since it 
is a more stable address. 


The IPv4/IPv6 address in the Value Field of the Interface ID TLV 
[RFC3471] 


This address identifies the data channel associated with the 
signaling message. In all cases, the data channel is indicated by 
the use of the data plane local interface address at the upstream 
LSR, that is, at the sender of the Path message. 
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See Section 6.2 for a description of these fields when bundled links 
are used. 

4.2.4. Explicit Route Object (ERO) 


The IPv4/IPv6 address in the ERO provides a data-plane identifier of 
an abstract node, TE node, or TE link to be part of the signaled LSP. 


See Section 6 for a description of the use of addresses in the ERO. 
4.2.5. Record Route Object (RRO) 
The IPv4/IPv6 address in the RRO provides a data-plane identifier of 


either a TE node or a TE link that is part of an LSP that has been 
established or is being established. 


See Section 6 for a description of the use of addresses in the RRO. 
4.2.6. IP Packet Source Address 


GMPLS signaling messages are encapsulated in IP. The IP packet 
Source address is either an IPv4 or IPv6 address and must be a 
reachable control plane address of the node sending the TE message. 
In order to provide control plane robustness, a stable IPv4 or IPv6 
control plane address (for example, the TE Router ID) can be used. 


Some implementations may use the IP source address of a received IP 
packet containing a Path message as the destination IP address of a 
packet containing the corresponding Resv message (see Section 4.2.7). 
Using a stable IPv4 or IPv6 address in the IP packet containing the 
Path message supports this situation robustly when one of the control 
plane interfaces is down. 


4.2.7. IP Packet Destination Address 


The IP packet destination address for an IP packet carrying a GMPLS 
signaling message is either an IPv4 or IPv6 address, and must be 
reachable in the control plane if the message is to be delivered. It 
must be an address of the intended next-hop recipient of the message. 
That is, unlike RSVP, the IP packet is not addressed to the ultimate 
destination (the egress). 


For a Path message, a stable IPv4 or IPv6 address of the next-hop 
node may be used. This may be the TE Router ID of the next-hop node. 
A suitable address may be determined by examining the TE 
advertisements for the TE link that will form the next-hop data link. 
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A Resv message is sent to the previous-hop node. The IPv4 or IPv6 
destination of an IP packet carrying a Resv message may be any of the 
following: 


o The IPv4 or IPv6 source address of the received IP packet 
containing the Path message. 


O A stable IPv4 or IPv6 address of the previous node found by 
examining the TE advertisements for the upstream data plane 
interface. 


o The value in the received in the Next/Previous Hop Address field 
of the RSVP HOP (PHOP) Object [RFC2205]. 


5. Unnumbered Addressing 


An unnumbered address is the combination of a network-unique node 
identifier and a node-unique interface identifier. 


An unnumbered link is identified by the combination of the TE Router 
ID that is a reachable address in the control plane and a node-unique 
Interface ID [RFC3477]. 


5.1. Unnumbered Addresses in IGPs 


In this section, we consider unnumbered address advertisement using 
OSPF-TE and IS-IS-TE. 


5.1.1. Link Local/Remote Identifiers in OSPF-TE 


Link Local and Link Remote Identifiers are carried in OSPF using a 
single sub-TLV of the Link TLV [RFC4203]. They advertise the IDs of 
an unnumbered TE link's local and remote ends, respectively. Link 
Local/Remote Identifiers are numbers unique within the scopes of the 
advertising LSR and the LSR managing the remote end of the link 
respectively [RFC3477]. 


Note that these numbers are not network-unique and therefore cannot 
be used as TE link end identifiers on their own. An unnumbered TE 
link end network-wide identifier is comprised of two elements as 
defined in [RFC3477]: 


- A TE Router ID that is associated with the link local end 


— The link local identifier. 
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5.1.2. Link Local/Remote Identifiers in IS-IS-TE 


The Link Local and Link Remote Identifiers are carried in IS-IS using 
a single sub-TLV of the Extended IS Reachability TLV. Link 
identifiers are exchanged in the Extended Local Circuit ID field of 
the "Point-to-Point Three-Way Adjacency" IS-IS Option type [RFC4205]. 


The same discussion of unique identification applies here as in 
Section 5.1.1. 


5.2. Unnumbered Addresses in RSVP-TE 


We consider in this section the interface ID fields of objects used 
in RSVP-TE in the case of unnumbered addressing. 


5.2.1. Sender and End Point Addresses 


The IP Tunnel End Point Address in the RSVP Session Object and the IP 
Tunnel Sender Address in the RSVP Sender Template Object cannot use 
unnumbered addresses [RFC3209], [RFC3473]. 


5.2.2. IF ID RSVP_HOP Object for Unnumbered Interfaces 


The interface ID field in the IF INDEX TLV specifies the interface of 
the data channel for an unnumbered interface. 


In both Path and Resv messages, the value of the interface ID in the 
IF INDEX TLV specifies the local interface ID of the associated data 
channel at the upstream node (the node sending the Path message and 
receiving the Resv message). 


See Section 6.2 for a description of the use bundled links. 
5.2.3. Explicit Route Object (ERO) 


The ERO may use an unnumbered identifier of a TE link to be part of 
the signaled LSP. 


See Section 6 for a description of the use of addresses in the ERO. 
5.2.4. Record Route Object (RRO) 

The RRO records the data-plane identifiers of TE nodes and TE links 

that are part of an LSP that has been established or is being 


established. TE links may be identified using unnumbered addressing. 


See Section 6 for a description of the use of addresses in the RRO. 
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5.2.5. LSP_Tunnel Interface ID Object 


The LSP_TUNNEL_INTERFACE_ID Object includes the LSR’s Router ID and 
Interface ID, as described in [RFC3477], to specify an unnumbered 
Forward Adjacency Interface ID. The Router ID of the GMPLS-capable 
LSR must be set to the TE Router ID. 


5.2.6. IP Packet Addresses 
IP packets can only be addressed to numbered addresses. 
6. RSVP-TE Message Content 


This section examines the use of addresses in RSVP EROs and RROs, the 
identification of component links, and forwarding addresses for RSVP 
messages. 


6.1. ERO and RRO Addresses 


EROs may contain strict or loose hop subobjects. These are discussed 
separately below. A separate section describes the use of addresses 
in the RRO. 


Implementations making limited assumptions about the content of an 
ERO or RRO when processing a received RSVP message may cause or 
experience interoperability issues. Therefore, implementations that 
want to ensure full interoperability need to support the receipt for 
processing of all ERO and RRO options applicable to their hardware 
capabilities. 


Note that the phrase "receipt for processing" is intended to indicate 
that an LSR is not expected to look ahead in an ERO or process any 
subobjects that do not refer to the LSR itself or to the next hop in 
the ERO. An LSR is not generally expected to process an RRO except 
by adding its own information. 


Note also that implementations do not need to support the ERO options 
containing Component Link IDs if they do not support link bundling 
[RFC4201]. 
ERO processing at region boundaries is described in [RFC4206]. 

6.1.1. Strict Subobject in ERO 
Depending on the level of control required, a subobject in the ERO 
includes an address that may specify an abstract node (i.e., a group 


of nodes), a simple abstract node (i.e., a specific node), ora 
specific interface of a TE link in the data plane [RFC3209]. 
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A hop may be flagged as strict (meaning that the LSP must go directly 
to the identified next hop without any intervening nodes), or loose. 


If a hop is strict, the ERO may contain any of the following. 
1. Address prefix or AS number specifying a group of nodes. 
2. TE Router ID identifying a specific node. 

3. Link ID identifying an incoming TE link. 


4. Link ID identifying an outgoing TE link, optionally followed by a 
Component Interface ID and/or one or two Labels. 


5. Link ID identifying an incoming TE link, followed by a Link ID 
identifying an outgoing TE link, optionally followed by a 
Component Interface ID and/or one or two Labels. 


6. TE Router ID identifying a specific node, followed by a Link ID 
identifying an outgoing TE link, optionally followed by a 
Component Interface ID and/or one or two Labels. 


7. Link ID identifying an incoming TE link, followed by a TE Router 
ID identifying a specific node, followed by a Link ID identifying 
an outgoing TE link, optionally followed by Component Interface ID 
and/or one or two Labels. 


The label value that identifies a single unidirectional resource 
between two nodes may be different from the perspective of upstream 
and downstream nodes. This is typically the case in fiber switching 
because the label value is a number indicating the port/fiber. It 
may also be the case for lambda switching, because the label value is 
an index for the lambda in the hardware and may not be a globally 
defined value such as the wavelength in nanometers. 


The value of a label in any RSVP-TE object indicates the value from 
the perspective of the sender of the object/TLV [RFC3471]. 
Therefore, any label in an ERO is given using the upstream node's 
identification of the resource. 
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6.1.2. Loose Subobject in ERO 


There are two differences between Loose and Strict subobjects. 


o A subobject marked as a loose hop in an ERO must not be followed 
by a subobject indicating a label value [RFC3473]. 


o A subobject marked as a loose hop in an ERO should never include 
an identifier (i.e., address or ID) of the outgoing interface. 


There is no way to specify in an ERO whether a subobject identifies 
an incoming or outgoing TE link. Path computation must be performed 
by an LSR when it encounters a loose hop in order to resolve the LSP 
route to the identified next hop. If an interface is specified as a 
loose hop and is treated as an incoming interface, the path 
computation will select a path that enters an LSR through that 
interface. If the interface was intended to be used as an outgoing 
interface, the computed path may be unsatisfactory and the explicit 
route in the ERO may be impossible to resolve. Thus a loose hop that 
identifies an interface should always identify the incoming TE link 
in the data plane. 


6.1.3. -RRO 


The RRO is used on Path and Resv messages to record the path of an 
LSP. Each LSR adds subobjects to the RRO to record information. The 
information added to an RRO by a node should be the same in the Path 
and the Resv message although there may be some information that is 
not available during LSP setup. 


One use of the RRO is to allow the operator to view the path of the 
LSP. At any transit node, it should be possible to construct the 
path of the LSP by joining together the RRO from the Path and the 
Resv messages. 


It is also important that a whole RRO on a Resv message received at 
an ingress LSR can be used as an ERO on a subsequent Path message to 


completely recreate the LSP. 


Therefore, when a node adds one or more subobjects to an RRO, any of 
the following options is valid. 


1. TE Router ID identifying the LSR. 


2. Link ID identifying the incoming (upstream) TE link. 


3. Link ID identifying the outgoing (downstream) TE link, optionally 
followed by a Component Interface ID and/or one or two Labels. 
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4. Link ID identifying the incoming (upstream) TE link, followed by a 
Link ID identifying the outgoing (downstream) TE link, optionally 
followed by a Component Interface ID and/or one or two Labels. 


5. TE Router ID identifying the LSR, followed by a Link ID 
identifying the outgoing (downstream) TE link, optionally followed 
by a Component Interface ID and/or one or two Labels. 


6. Link ID identifying the incoming (upstream) TE link, followed by 
the TE Router ID identifying the LSR, followed by a Link ID 
identifying the outgoing (downstream) TE link, optionally followed 
by a Component Interface ID and/or one or two Labels. 


An implementation may choose any of these options and must be 
prepared to receive an RRO that contains any of these options. 


6.1.4. Label Record Subobject in RRO 


RRO Label recording is requested by an ingress node setting the Label 
Recording flag in the SESSION_ATTRIBUTE object and including an RRO 
is included in the Path message as described in [RFC3209]. Under 
these circumstances, each LSR along the LSP should include label 
information in the RRO in the Path message if it is available. 


As described in [RFC3209], the processing for a Resv message "mirrors 
that of the Path" and "The only difference is that the RRO in a Resv 
message records the path information in the reverse direction." This 
means that hops are added to the RRO in the reverse order, but the 
information added at each LSR is in the same order (see Sections 
6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, 
labels are included in the RROs in both the Path and Resv messages. 


6.2. Component Link Identification 


When a bundled link [RFC4201] is used to provide a data channel, a 
component link identifier is specified in the Interface 
Identification TLV in the IF_ID RSVP_HOP Object in order to indicate 
which data channel from within the bundle is to be used. The 
Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of 
an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV 

(Type 2) in the case of a numbered component link. 


The component link for the upstream data channel may differ from that 
for the downstream data channel in the case of a bidirectional LSP. 
In this case, the Interface Identification TLV specifying a 
downstream interface is followed by another Interface Identification 
TLV specifying an upstream interface. 
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6. 


7. 


i 


7. 


Note that identifiers in TLVs for upstream and downstream data 
channels in both Path and Resv messages are specified from the 
viewpoint of the upstream node (the node sending the Path message and 
receiving the Resv message), using identifiers belonging to the node. 


An LSR constructing an ERO may include a Link ID that identifies a 
bundled link. If the LSR knows the identities of the component links 
and wishes to exert control, it may also include component link 
identifiers in the ERO. Otherwise, the component link identifiers 
are not included in the ERO. 


When a bundled link is in use, the RRO may include the Link ID that 
identifies the link bundle. Additionally, the RRO may include a 
component link identifier. 


3. Forwarding Destination of Path Messages with ERO 


The final destination of the Path message is the Egress node that is 
specified by the tunnel end point address in the Session object. 


The Egress node must not forward the corresponding Path message 
downstream, even if the ERO includes the outgoing interface ID of the 


Egress node for Egress control [RFC4003]. 


Topics Related to the GMPLS Control Plane 


.1. Control Channel Separation 


In GMPLS, a control channel can be separated from the data channel 
and there is not necessarily a one-to-one association of a control 
channel to a data channel. Two nodes that are adjacent in the data 
plane may have multiple IP hops between them in the control plane. 


There are two broad types of separated control planes: native and 
tunneled. These differ primarily in the nature of encapsulation used 
for signaling messages, which also results in slightly different 
address handling with respect to the control plane address. 


1.1. Native and Tunneled Control Plane 


A native control plane uses IP forwarding to deliver RSVP-TE messages 
between protocol speakers. The message is not further encapsulated. 


IP forwarding applies normal rules to the IP header. Note that an IP 
hop must not decrement the TTL of the received RSVP-TE message. 


For the case where two adjacent nodes have multiple IP hops between 
them in the control plane, then as stated in Section 9 of [RFC3945], 
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implementations should use the mechanisms of Section 6.1.1 of 

[RFC4206] whether or not they use LSP Hierarchy. Note that Section 
6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, 
but also to a "TE link" for the case where a normal TE link is used. 


With a tunneled control plane, the RSVP-TE message is packaged in an 
IP packet that is inserted into a tunnel such that the IP packet will 
traverse exactly one IP hop. Various tunneling techniques can be 
used including (but not limited to) IP-in-IP, Generic Routing 
Encapsulation (GRE), and IP in MPLS. 


Where the tunneling mechanism includes a TTL, it should be treated as 
for any network message sent on that network. Implementations 
receiving RSVP-TE messages on the tunnel interface must not compare 
the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel 
TTE). 


It has been observed that some implementations do not support the 
tunneled control plane features, and it is suggested that to enable 
interoperability, all implementations should support at least a 
native control plane. 


7.2. Separation of Control and Data Plane Traffic 


Data traffic must not be transmitted through the control plane. This 
is crucial when attempting PSC (Packet-Switching Capable) GMPLS with 
separated control and data channels. 


8. Addresses in the MPLS and GMPLS TE MIB Modules 


This section describes a method of defining or monitoring an LSP 
tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD- 
MIB module [RFC4802] where the ingress and/or egress routers are 
identified using 128-bit IPv6 addresses. This is the case when the 
mplsTunnellngressLSRId and mplsTunnelEgressLSRId objects in the 
mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end 
point address and Extended Tunnel Id fields from the signaled Session 
Object because the IPv6 variant (LSP TUNNEL IPv6 SESSION object) is 
in use. 


The normative text for MIB objects for control and monitoring MPLS 
and GMPLS nodes is found in the RFCs referenced above. This section 
makes no changes to those objects, but describes how they may be used 
to provide the necessary function. 
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8.1. Handling IPv6 Source and Destination Addresses 
8.1.1. Identifying LSRs 


For this feature to be used, all LSRs in the network must advertise a 
32-bit value that can be used to identify the LSR. In this document, 
this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the 
OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. 
Note that these are different from TE router ID (see Section 2). 


8.1.2. Configuring GMPLS Tunnels 


When setting up RSVP TE tunnels, it is common practice to copy the 
values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields 
in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel 
ID and IPv4 tunnel end point address fields, respectively, in the 
RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209]. 


This approach cannot be used when the ingress and egress routers are 
identified by 128-bit IPv6 addresses as the mplsTunnellngressLSRId, 
and mplsTunnelEgressLSRId fields are defined to be 32-bit values 
[RFC3811], [RFC3812]. 


Instead, the IPv6 addresses should be configured in the mplsHopTable 
as the first and last hops of the mplsTunnelHopTable entries defining 
the explicit route for the tunnel. Note that this implies that a 
tunnel with IPv6 source and destination addresses must have an 
explicit route configured, although it should be noted that the 
configuration of an explicit route in this way does not imply that an 
explicit route will be signaled. 


In more detail, the tunnel is configured at the ingress router as 
follows. See [RFC3812] for definitions of MIB table objects and for 
default (that is, "normal") behavior. 


The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 


The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be 
set to 32-bit LSR IDs for ingress and egress LSRs, respectively. 


The mplsTunnelHopTableIndex must be set to a non-zero value. That 
is, an explicit route must be specified. 


The first hop of the explicit route must have mplsTunnelHopAddrType 
field set to ipv6(2) and should have the mplsTunnelHopIpAddr field 
set to a global scope IPv6 address of the ingress router that is 
reachable in the control plane. 
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The last hop of the explicit route must have mplsTunnelHopAddrType 
field set to ipv6(2) and should have the mplsTunnelHopIpAddr field 
set to a global scope IPv6 address of the egress router that is 
reachable in the control plane. 


The ingress router should set the signaled values of the Extended 


Tunnel ID and IPv6 tunnel end point address fields, respectively, of 
the RSVP-TE LSP TUNNEL IPv6 SESSION object [RFC3209] from the 
mplsTunnelHopIpAddr object of the first and last hops in the 
configured explicit route. 


8.2. Managing and Monitoring Tunnel Table Entries 


In addition to their use for configuring LSPs as described in Section 
8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be 
used for managing and monitoring MPLS and GMPLS TE LSPs, 
respectively. This function is particularly important at egress and 
transit LSRs. 


For a tunnel with IPv6 source and destination addresses, an LSR 
implementation should return values in the mplsTunnelTable as follows 
(where "normal" behavior is the default taken from [RFC3812]). 


The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 


The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 
32-bit LSR IDs. That is, each transit and egress router maps from 
the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID 
of the ingress LSR. Each transit router also maps from the IPv6 
address in the IPv6 tunnel end point address field to the 32-bit LSR 
ID of the egress LSR. 


9. Security Considerations 


In the interoperability testing we conducted, the major issue we 
found was the use of control channels for forwarding data. This was 
due to the setting of both control and data plane addresses to the 
same value in PSC (Packet-Switching Capable) equipment. This 
occurred when attempting to test PSC GMPLS with separated control and 
data channels. What resulted instead were parallel interfaces with 
the same addresses. This could be avoided simply by keeping the 
addresses for the control and data plane separate. 
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